This topic is under discussion on the following forum: oesf.org. Please feel free to post any comments, criticism, suggestions, etc. You can also e-mail me directly as albertr at iral com.
The OHCI USB host controller in Intel PXA270 has three ports. Two of them (port1 & port2) have differential signal lines. The data lines (D+ & D-) for port2 are multiplexed to USB OTG connector on the back of the Zaurus. Port1 is also traced on the PCB as shown on the following picture (click on image to see larger picture):
Only data lines are traced, power control lines are not.
As a proof of the concept, a small:
DELL TrueMobile 350 bluetooth usb module was wired to port1 with the flying leads. The traces on Zaurus's PCB are very tiny, so extra care needs to be taken not to destroy the PCB. LEGAL DISCLAIMER: Please note that I don't take any responsibility for any possible damage done to your Zaurus should you consider following this article and trying soldering. Any information published here is NOT an advise, and any actions you do is your own sole responsibility. Also, I'm not responsible for any incorrect information, typos, errors and omissions. Well, that said, we all know that we want to have internal wireless networking on the Z, but unless done by the person experienced in soldering, the Zaurus is probably not the best object to practice on. Another thing to consider is that any hardware modifications would void Sharp's warranty.
On this picture the joints are covered with a transparent non-conductive glue to prevent possible damage from accidentially pulling the wires. The SL-C1000 is shown, but the PCB design is shared between all PXA270-based Zaurii - C1000/C3000/C3100.
Not sure if the module was defective or CSR's firmware (it uses CSR BC04-Ext chipset which is BT 1.2 certified and supports enhanced data rates) that didn't play nicely with PXA270 OHCI controller, but unfortunately it didn't work:
Well, the good thing is that the wiring was correct and when I've tried to replace this module with an Intersil Prism3-based usb 802.11b module, it did work!
This Prism3-based usb module identifies itself as Acer WarpLink 802.11b Adapter. It's supported by wlan-ng drivers under Linux and by wi driver under OpenBSD. It's quite large, but thick and it fits inside C1000's casing when placed on top of missing CF buffer ASIC. Also, this module has a connector for external antenna and two LEDs (one is very cool blue color used by the module itself and another one is traced to the contact pad, so it could be used by other components). Here's how it compares in size with a CF card:
Since the port1 has differential data lines, the wiring schemantics could be as simple as the following (simplified diagram):
____________ ____________ | | | | | D+ o------------------------------o D+ | | D- o------------------------------o D- | | | | | | VCC o------------------------------o VCC | | GND o------------------------------o GND | | | | | | HOST | | CLIENT | ------------ ------------assuming that VCC is provided by the HOST - Zaurus.
The Zaurus's OTG connector and surrounding logic use three GPIO pins:
I've never used the Zaurus as an USB client (nor had any desire to do that in future), so I'd rather give up on USB client functionality in exchange of two extra GPIO pins (GPIO41 & GPIO35). That means that OTG is switched to host mode permanently, and there's no need to run usb-monitor anymore. Also, it could simplify things a bit in regards of that now we can make an assumption that both host ports can be controlled by the driver in the similar fashion and that the 5V OTG power could be switched ON/OFF at our will (don't have to worry of checking if another host is connected to OTG and supplies its own power). On the other hand, if we don't really need to re-purpose these two GPIO's, it shouldn't be difficult to maintain both USB host and client functionalities for OTG.
I decided to drop usb client functionality completely and to change the Sharp's OHCI glue driver accordingly. The new driver is a drop-in replacement for the old one and available here. Please note that this driver is in early beta stages and might have problems. I'll try to do my best to maintain it (time permitting), so any patches / suggestions / comments are appreciated.
A few things to note when using this driver:
Also the software control over the 5V OTG power domain is now separated from the driver and is implemented as a command-line utility available here.
The Zaurus has a dedicated power domain 5V OTG to power up devices connected to the USB OTG connector. It uses TOKO's TK3850 5V voltage regulator with input voltage drawn from 5V domain. There's a cut-off over-current protection @ ~200mA implemented by a 5.7K resistor on TK3850's PCL pin.
This limit could be lifted to:
There's no cut-off limit if PCL is grounded. According to TK3850's datasheet there's a ~170mV voltage dropout @ 500mA load.
Here's what the datasheet says about power dissipation on p.4:
Expected power dissipation is 1.1W or less when mounted on a PCB substrate. Instantaneous power dissipation due to short circuit can reach 13W when the input voltage is 12V or more. This condition creates a very rapid temperature rise and may result in the chip catching on fire. When experimenting with this part please note that there is no instantaneous short circuit protection if the input voltage is 12V or more and the PCL function is not being used. However, if the short-circuit current is set to 500mA or less by using the PCL function, nothing will be damaged because the maximum input power is limited even when the input potential is high. (If the input voltage goes up, the output current increases, or the ambient temperature rises the internal thermal shutdown sensor will protect the IC). When the thermal sensor works, the regulator will shut off. As the junction temperature decreases, the regulator will begin to operate again. Under sustained fault conditions the regulator output will oscillate as the device turns off then resets. Please improve heat radiation or lower the input electric power.
According to the following post by Boris, it should be safe to draw ~500mA from this regulator. I'm using it for a few weeks now with a 1K resistor on the PCL pin, and it seems to be providing sufficient current to power both internal Wi-Fi and bluetooth modules at the same time.
Here's a picture of 5V OTG power regulator:
Does anyone know what is the IC that reads:
7310A TE506 NIAC?
There's some I/O expansion ASIC that speaks I2C and is used on C1000 instead of Scoop2. Could it be it?
Here's something that looks awfully like the pin-out of Mitsumi WML-C19 bluetooth module used by Sharp in SL-6000 series:
Please note that on the picture above RX is connected to BTUART's TX and vise versa, so no crossing over is necessary. The same is true for CTS and RTS.
To enable traces to Mitsumi WML-C19 pads, the following contact points need to be connected in the CPU compartment located under the metal shielding with a resistor array (in [1] on p.20-2 Intel recommends to use 10 - 25 Ohm nominal resistance):
BEFORE |
AFTER |
|---|---|
 |
 |
If BTUART is not used or used to connect to CSR-based bluetooth module via BSCP protocol, CTS and RTS lines can be re-purposed as GPIO pins 44 and 45.
Sharp's serial driver is not quite up to the task. The "de-sharped" driver is available here.
The following two small modules were used in this project: the old revision of CSR BC02-Ext-based USB bluetooth 1.1 dongle from Billionton and an unexpensive ZyDAS ZD1211-based 802.11a/b/g USB dongle from Zonet:
There's a CF card underneath the modules, so you can see how it compares size-wise.
Here's another shot showing how does it fit into Z's compartment:
ZD1211 has linux drivers available here. While the driver is rather fat, messy and undocumented, it seems to be getting somewhat stable lately. It supports both 2.4 and 2.6 kernels, WPP/WPA2, master and monitor modes. While ZD1211 chipset supports all 802.11a/b/g freq's and modulations, the driver will work in 802.11b mode only if attached to USB 1.1 bus. With theoretical throughput of 12Mb/s, USB 1.1 effective transfer rate would max out at ~8.8Mbit/s (but could be worse in practice), so there's not much room even for 802.11b.
CSR BC02-Ext is well supported in Linux bluetooth stacks - BlueZ, Affix and OpenBT. It can be used with proprientary BCSP serial protocol, which essentially allows to get away without using hardware flow control, and thus re-purpose CTS and RTS lines on Zaurus as GPIO pins 44 and 45. Since it's sold as an USB dongle, it uses USB interface by default, but could be re-programmed to switch to serial UART interface. I used the same module before in the following projects: Psion5mx and Simpad. The other thing to note about CSR modules is that they have so-called "deep-sleep" power saving mode which can be enabled by sending break signal. Also this module has a dedicated reset line, which can be controlled by GPIO pin.
bccmd from bluez-utils package was used to switch the module from USB to BCSP UART protocol. This module seem to work fine @ 921800 baud speed with BlueZ on the Zaurus. The module pinout can be found here.
Here's a picture of working prototype that uses these modules:
The schemantic "C" from the drawing kindly provided by Boris was used to control the power, as pictured below:
Here's the pictures of assembled PCB:
The small cut was done in metal shielding that lays under the keypad to reduce blocking of RF signal. Here's how this opening relates to antenna's locations:
There's a LED wired up to ZD1211 with flying leads:
There're a few things worth to notice about SL-C1000:
I'm using these two GPIO pins on my C1000 to control power from 5V OTG regulator to internal Wi-Fi and bluetooth modules and it doesn't seem to interfere with anything on C1000.
Below are some small bits and pieces which I didn't personaly use and thus didn't have a chance to test out. I have reasonable belief that it might be useful, but please test it before trying to use, since it's untested at the moment.
There're two GPIO's traced to test/debug pads. They don't seem to be used in the Linux kernel on Zaurus, but mught be used by Sharp's bootloader or testing/maintenance software:
Here's some GPIO pins used by Sharp's OTG implementation. In order to re-purpose GPIO41, R1 resistor needs to be removed to disconnect the line from the OTG connector.
It's possible that 5V could be found on pins 1,2 and 3 of LCD connector (please test it before using, since it's untested at the moment):
EOF
Did you find this information useful? Please consider donating to the cause of exploration...
You can reach me at albertr at iral dot com.